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SPECIFICATION 



SYSTEM AND METHOD FOR MANAGING OPERATING SYSTEMS 

TECHNICAL FIELD 

The present invention relates to a system for managing 
information item of a plurality of operating systems. More 
particularly, the present invention relates to a system for 
managing and editing/displaying trace log information of a 
plurality of operating systems (hereafter, to be 
abbreviated as OS in some cases). 

BACKGROUND ART 

In the case of a system for executing processes under 
the control of a plurality of different operating systems 
in accordance with a real time processing, a general 
information processing, an interchanging processing 
between old and new items, and other processes, the user will 
wish to manage the operations of those operating systems 
cons is tently . 

This is why conventional operating system management 
systems, when managing trace log information items, have 
enabled each of those operating systems to execute a trace 
log editing/displaying program and have trace log 
information in itself. And, as disclosed in the official 
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gazette of Unexamined Published Japanese Application 
No. 9-134300, when editing error log information items 
collected by a plurality of operating systems installed in 
a plurality of host computers, those conventional systems 
5 have used a well-known method, which sorts and merges such 

error log information items sequentially in order of times 
at which they are generated. 

However, each operating system makes time management 
% by its own way and usually calculates an elapsed time with 

r L- 10 use of a timer interruption, etc. , thereby updating the time 

; ,y managed by itself. Consequently, such the time managing 

method has been divided clearly into two types; the times 
of all the operating systems are adjusted to the time of any 

• ! W one of those operating systems as disclosed in the official 

fU 

0 15 gazette of Unexamined Published Japanese Application 

H s 

No. 6-332568 and/or No. 5-307424 or the times of all those m 
the time of a reference operating system. 

However, the time management method differs among 
types of operating systems. If a plurality of operating 

20 systems are running in a computer, therefore, the 

interruption processing method and the processing timing 
will also differ among those operating systems . And 
accordingly, the times managed by those operating systems 
do not agree to each another. Consequently, event trace log 

25 information items collected by those operating systems 
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cannot be merged in order of times at which they are 
generated through an arithmetic operation performed by an 
operator or a computer as disclosed in the above 
conventional technology. This is because the times of 
5 managed by those operating systems are different from each 

another. 

Under the circumstances, it is an object of the 
present invention to provide an operating system management 
system for enabling each operating system to manage its time 
10 by itself and managing a sequence of events generated among 

those operating systems accurately. 



DISCLOSURE OF THE INVENTION 

In order to achieve the above object, the operating 

15 system management system of the present invention manages 

the correspondence among the times managed by a plurality 
of operating systems running in one computer. Consequently, 
traces, which become check points, are recorded in the trace 
information of those operating systems so that those check 

20 points are regarded to have been generated approximately at 

the same time. In addition, the operating system management 
system of the present invention adds a counter value to the 
trace information of each of those operating systems as 
additional information and manages the correspondence among 
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the times managed by those operating systems running in one 
computer . 

The operating system management system is provided 
with means for editing/displaying a trace information 
5 sequence of events in order they are generated and recorded 

by those operating systems in order their events are 
generated according to the correspondence among the traces 
to be assumed as check points, added counter values, or times 
! ^ ! managed by those operating systems. When displaying event 

10 data items related to a plurality of operating systems, the 

i: 3:: 

u[ management system adjusts the sequence for displaying 

events according to the correspondence among those events 

M< in those operating systems so as to adjust the sequence of 

Q 

i'U the times of those events. 

m 

O 15 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig.l is an overall block diagram of a trace log 
management system of the present invention. 

Fig. 2 is a hardware block diagram of the trace log 
20 management system of the present invention. 

Fig. 3 is a schematic flowchart of the operation of the 
trace log management system of the present invention. 

Fig. 4 is a model case for an operating system 
switching trace employed as a check point trace. 



Fig. 5 shows how traces are displayed in the first 
embodiment of the present invention. 

Fig. 6 shows a model case for a variation of the first 
embodiment . 

Fig. 7 shows a model case for another variation of the 
first embodiment. 

Fig. 8 is a block diagram of the trace log 
editing/displaying system in the second embodiment of the 
present invention. 

Fig. 9 is another block diagram of the trace log 
editing/displaying system in the second embodiment of the 
present invention. 

Fig. 10 shows a computer for operating a trace log 
editing/displaying program in another embodiment of the 
trace log management system of the present invention. 

BEST MODE FOR CARRYING OUT THE INVENTION 

Hereunder, a description will be made in detail for 
the embodiments of an operating system management method of 
the present invention with reference to the accompanying 
drawings. The operating system management method is 
employed for a trace log editing/displaying system used to 
trace and display events of a plurality of operating 
systems . 
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The trace log editing/displaying system in the first 
embodiment of the present invention is applied to a trace 
result to be assumed as a check point (to be referred to as 
a check point trace), which is an event logs corresponded 
5 to those of other operating systems as an operation 

information item used as a time reference of operation 
information items regarded to have been generated 
approximately at the same time among those operating 
systems. Fig.l shows a schematic block diagram of a trace 

10 log editing/displaying system of the present invention. In 

one computer 101 are installed the first operating system 
310 (to be abbreviated as OS1) and the second operating 
system 320 (to be abbreviated as OS2 ) . A control program 
201 manages the operation states of a plurality of operating 

15 systems (OS1 and OS2 ) . In this embodiment, it is premised 

that the OS1 and the OS2 are replaced alternately and 
operated in a time sharing manner. The OS1 has time 
information 312 managed by itself and operation trace 
information 311 representing the operation history thereof 

20 based on this time information 312. In the same way, the 

OS2 has time information 322 managed by itself and operation 
trace information 321. What is notable here is that the 
times 312 and 322 managed by OS1 and OS 2 do not always agree 
to each other. In this embodiment, a trace log 

25 editing/displaying program 401 is operating under the 
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control of the OS1. The program 401 edits and displays 
operation trace information items collected by operating 
systems. The program 401 can also run under the control of 
the OS2. 

5 The control program 201 enables each operating system 

to store a check point trace in both operation trace 
information 311 of the OS1 and operation trace information 
321 of the OS2 (801, 802). This checkpoint trace is a trace 
of an event corresponded to each operating system. The check 
10 point trace is an operation information item generated 

commonly in both 0S1 and OS2 and used as a time difference 

a:; 

among those operating systems. Consequently, it is only 
required for a recorded check point trace that at least it 
is corresponded to each operating system. It is not required 

Pi i 

15 necessarily that it is recorded completely in the same way 

in the log of each operating system. The trace log 
editing/displaying program 401 reads the operation trace 
information 311 recorded in the OS1 and the operation trace 
information 321 recorded in the OS2 (803, 804). The trace 
20 log editing/displaying program 401 searches a check point 

trace from two operation trace information items 311 and 
321. If the object check point trace is found, the program 
104 finds the correspondence of the trace among the check 
point traces of other operating systems. Then, even when 
25 the times of the check point traces recorded by operating 
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sys terns differ from each other, the trace log 
editing/displaying program 401 regards that the traces are 
generated actually at the same time, thereby editing traces 
included in two operation trace information items (805) and 
5 displaying the result on the display unit 102 (806). 

Fig. 2 is a hardware block diagram of a computer system 
for realizing the trace log editing/displaying system of the 
present invention. In this computer 101, a computing unit 
104 is connected to a system bus via an address converter 
^ 10 107. The system bus 101 is connected to a main memory 103, 

f-- 1 an interruption device 108, a timer 109, and a video adapter 

F 111. The video adapter 111 is connected to a display unit 

H' 102. The main memory 103 is shared by a plurality of 

O 

IU operating systems (OS1 and OS2). The main memory 103 is 

fU 

□ 15 roughly divided into a common area 103-1 used commonly by 

j t ci, 

those operating systems, an OS1 area 103-2, and an OS2 area 
103-3. The common area 103-1 stores a control program 201. 
The OS1 area 103-2 is a memory area used to operate the OS1. 
The OS1 area 103-2 stores the OS1 program 310 itself, OS1 

20 managed time information 312, and OS1 operation trace 

information 311. In the same way, the OS2 area 103-3 stores 
the OS2 program 320 itself, OS2 managed time information 
322, and OS2 operation trace information 321. And, two 
address registers (105 and 106) are provided and used to 

25 store the address of each area provided in the main memory. 
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The address register 105 specifies the common area 103-1 and 
the address register 106 is selected by the control program 
201 and it specifies an area of the present running operating 
system. In Fig. 2, the address register 106 specifies the 
5 OSl area 103-2. This means that the OS1 is executed by the 

control program 2 01. 

Fig. 3 shows a schematic flowchart of the operation of 
the trace log editing/displaying system of the present 
:;; invention. At first , check point traces are stored in the 

[! :;; 10 OSl operation trace information and the OS2 operation trace 

| u information beforehand (801 and 802). To display the 

••K operation trace information of both OSl and OS2 in order they 

H are generated, the trace log editing/displaying program 

ill reads both OSl operation trace information and OS2 operation 

Q 15 trace information (803 and 804). Searching the OSl 

[„!, 

operation trace information and the OS2 operation trace 
information, the trace log editing/displaying program finds 
check point traces that are regarded to have been generated 
simultaneously in operating systems OSl and OS2 from their 
20 trace information items. This trace information item is 

decided as a reference time of other times regarded 
approximately the same time in both OSl and OS2, then both 
OSl and OS2 trace information items are merged in order they 
are generated (step 805). The merged trace information 



items of both 0S1 and 0S2 are then displayed on the display 
unit ( step 806 ) . 

Next, a description will be made in detail for an 
embodiment of the control program 201 with reference to 
Figs. 4 and 5. The embodiment uses an OS switching trace as 
a check point trace. Fig. 4 shows a model case for a series 
of generated traces. In Fig. 4, the time axis is taken in 
the vertical direction. Actual OS1 operation states are 
shown at the left side and actual OS2 operation states are 
shown at the right side. In this embodiment, the OS1 and 
the OS2 run in one computer in a time sharing manner. It 
is premised here that the control program 201 changes 
operating systems. Thus, the OS1 and the OS2 never run 
simultaneously. A trace name Ax(x: 1 to 4) is given to each 
trace of the OS1 and a trace name Bx(x: 1 to 4) is given to 
each trace of the 0S2. SWz(z: 1 to 3 ) is given to each trace 
in which an operating system is switched to another, that 
is, a record that the state of an operating system is changed 
from "run" to "standby" or vice versa. This trace is common 
to both OS1 and OS2. 

At first, Al (501-1) was generated and traced at an 
OS1 managed time of 10:00:00. Then, A2 (501-2) was generated 
and traced at 10:00:01 and A3 (501-3) was traced at 10:00:03, 
both times were managed by the OS1. After that, an OS 
switching event was generated (503-1) at an OS1 managed time 
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of 10:00:05 in response to the command from the control 
program 201 and SW1 (501-4) was recorded in an OS1 trace, 
thereby the present operating system OS1 was changed to OS2. 
At this time, the OS2 managed time was 10:00:35. This means 
5 that the OS1 managed time and the OS2 managed time are 

different by 30 sec from each other. The OS2 thus recorded 
SW1 (502-1) as a trace according to the command for 
restarting the operation from the control program 2 01. The 
OS2 then started its operation and recorded traces of Bl 

10 (502-2) at the OS2 managed time 10:00:36 and B2 at 10:00:37 

respectively. Then, the operating system OS2 was changed 
to OS1 (503-2) at an OS1 managed time of 10:00:40. The OS1 
managed time at that time was 10:00:10. Just like in the 
above case, the SW2 traces (502-4, 501-5) were recorded in 

15 both OS1 and OS2 at that time. Hereafter, the events 

A4(501-6), SW3(501-7, 502-5), B3(502-6), and B4(502-7) were 
generated as described above and their traces were recorded. 

Those trace results are stored in both OS1 and OS2 
operation trace information items (311 and 321) in order of 

20 times managed by those operating systems. It is premised 

here that each trace is stored so as to be corresponded to 
its given name. The trace name may be a trace code managed 
by the corresponding operating system or the control program 
201. Consequently, Al to A4 and SWl to SW3 (501-1 to 501-7) 

25 are stored in the OS1 trace information in order they are 



generated in the 0S1 together with OS1 managed times. In 
the same way, Bl to B4 and SW1 to SW3 ( 502-1 to 502-7) are 
stored in the OS2 trace information 321 in order they are 
generated in the OS2 together with OS2 managed times. 

The trace log editing/displaying program 401 searches 
an SWz(z: 1 to 3 ) used as a check point trace from both OS1 
and 0S2 operation trace information items (311 and 321). 
Then, if there is at least one trace between SWz and SWz+1, 
it is decided that an operating system having the operation 
trace information is running during the time in which SWz 
and SWz+1 are recorded. If there is no trace found between 
SWz and SWz+1, it is decided that another operating system 
is running or the original operating system is running. In 
this embodiment, because Bl and B2 traces are found in the 
OS2 operation trace information between SWl and SW2, it is 
decided that the OS2 is running. And, an A4 trace is found 
between SW2 and SW3 , it is decided that the 0S1 is running. 
If it is considered that the OS1 and the OS2 are switched 
sequentially, it is decided that the OS1 is running before 
SWl and the OS2 is running in and after SW3 . 

If check point traces are to be corresponded to each 
other, generated check point traces are common to both OS1 
and OS2. Thus, the same number of check point traces come 
to be included in each of OS1 and 0S2 operation trace 
information items at equal time intervals regardless of 
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their managed time values. Consequently, event names or 
codes stored in each operation trace information are checked 
for agreement, as well as traces of common events assumed 
as check points are searched sequentially starting at the 
5 first one, thereby finding the traces that agree to each 

other. 

Fig. 5 shows results of trace data edited and displayed 
by the trace log editing/displaying program in order they 
are generated actually according to the operation trace 

10 information 311 of the IS1 and the operation trace 

information 312 of the OS2. In Fig. 5, OS switching traces 
SWz (z=l to 3), which are check point traces (SWl, SW2 , and 
SW3 ) , are displayed in a thick line frame respectively. 
Those OS switching traces may also be displayed in different 

15 colors. For example, SWz may be displayed in red and other 

traces may be displayed in black. 

Next, a variation of the first embodiment of the 
present invention will be described with reference to Fig. 6. 
In this embodiment, a synchronization trace is employed 

20 instead of an OS switching trace (check point trace) for 

which the control program 201 is used. The control program 
201 stores a synchronization trace at the same timing as 
those of the OS1 operation trace information 311 and the 0S2 
operation trace information 321 regardless of each OS 

25 status. Consequently, even when the 0S1 managed time 312 
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and the 0S2 managed time 322 are different from each other, 
a timer difference between those operating systems can be 
known through collation of operation trace information 
items of both 0S1 and OS2 according to this synchronization 
5 trace information. The trace generation sequence can thus 

be known. 

Fig. 6 shows a model case for a series of generated 
traces. In Fig. 6, the time axis is taken in the vertical 
direction. Actual operations of the 0S1 are shown at the 

10 left side and those of the OS2 are shown at the right side. 

In this embodiment, it is premised that 0S1 and OS2 are 
running in one computer in a time sharing manner. Thus, 0S1 
and OS2 are never executed simultaneously. A trace name 
Ax(x: 1 to 4) is given to each OS1 trace and a trace name 

15 Bx(x: 1 to 4) is given to each 0S2 trace. The trace name 

SI is a synchronization trace used as a check point trace 
in this embodiment. The trace is common to both OS1 and OS2. 

At first, the trace of Al (504-1) is recorded at an 
0S1 managed time 10:00:00 and the trace of A2 (504-2) is 

20 recorded at 10:00:01. Then, the trace of a synchronization 

SI (506-1) is recorded in both 0S1 operation trace 
information and 0S2 operation trace information at an OS1 
managed time 10:00 : 02 (504-3, 505-1). At this time, the OS2 
managed time was 10:00:32. Then, the trace of A3 (504-4) 

25 was recorded in OS2 at 10:00:03. After that, an OS switching 
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event (506-2) occurred/ thus control was passed to OS2. 
Then, the traces of Bl (505-2) and B2( 505-3) were recorded 
in OS2 at 10:00:36 and 10:00:37 respectively. Furthermore, 
an OS switching event (506-3) occurred, and the trace of A4 
5 ( 504-5 ) was recorded in OS1 . After the OS switching (506-4 ) , 

the traces of B3 (505-4) and B4( 505-5) were recorded in OS2 
respectively- After that, Al to A4 and SI (504-1 to 504-5) 
were stored as OS1 traces in the operation trace information 
311 together with the 0S1 managed times in order they were 

10 generated in OS1. In the same way, Bl to B4 and Sl(505- 

1 to 505-5) were stored as OS2 traces together with OS2 
managed times in order they were generated. 

The trace log editing/displaying program 401, when 
editing/displaying an actual sequence of generated traces 

15 according to both of the operation trace information 311 of 

the OS1 and the operation trace information 312 of the OS2, 
searches a check point synchronization trace from the 
operation trace information items of both OS1 and OS2. 
Finding the synchronization trace SI (504-3, 505-1), the 

20 program 401 decides the SI (504-3) stored in the OS1 

operation trace information 311 as a reference point. 
Because the SI (504-3) was generated at an 0S1 managed time 
of 10:00:02, the relative times at which other OS1 traces 
were generated is calculated with reference to this time as 

25 follows . 
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Relative time = trace generation time- reference 
point generation time 

It is thus found that Al takes -2sec, A2 takes -lsec, 
A3 takes lsec, and A4 takes lOsec. 
5 The relative times of OS2 traces are also calculated 

in the same way. Because the reference point SI (505-1) was 
generated at OS2 managed time 10:00:32, Bl takes 4 sec, B2 
takes 5sec, B3 takes 12sec, and B4 takes 13sec. These 
results are displayed so that the time axis is taken in the 

10 vertical direction (from top to bottom) and OSl traces are 

shown at the left side and OS2 traces are shown at the right 
side. Those traces are displayed in ascending order of 
calculation results of the above relative times from top to 
bottom in the format of one trace per line. Then, the 

15 synchronization traces (504-3 and 505-1), which were 

generated simultaneously in both OSl and OS2, are displayed 
on the same line. The synchronization traces are also 
displayed in a thick line frame respectively or in different 
colors. Consequently, traces of each OS are displayed 

20 sequentially from top to bottom in order they are actually 

generated. 

Furthermore, a description will be made for another 
variation of the first embodiment of the present invention 
with reference to Fig. 7. In this embodiment, instead of a 
25 check point trace recorded by the control program 201 as 



described above, an inter-OS communication trace (509-1) is 
used. In this embodiment, it is premised that data is 
transferred from OSl to OS2. The inter-OS communication 
means transferring of data from the transmission program of 
an operating system to the receiving program of another 
operating system. In this case, the transmission side 
program records transmission traces and the receiving side 
program records received traces. These transmission traces 
and received traces are referred to as inter-OS 
communication traces generically. In such the inter-OS 
communication > transmission and receiving are corresponded 
to each other and both transmission program and the 
receiving program are executed in a synchronized manner. It 
is thus regarded that inter-OS communication traces 
recorded in both OSl and OS2 are generated almost 
simultaneously. Consequently, even when the OSl managed 
time and the OS2 managed time are different from each other, 
a time difference between those operating systems can be 
known through collation with the operation trace 
information items of both OSl and OS2 according to this 
inter-OS communication trace information. This is why the 
sequence of generated traces can be known. 

Fig. 7 shows a model case for a series of generated 
traces. In Fig. 7, the time axis is taken in the vertical 
direction. Actual OSl operation states are shown at the left 
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side and actual OS2 operation states are shown at the right 
side. In this variation of the first embodiment , it is 
premised that both OS1 and 0S2 are executed in one computer 
in a time sharing manner. Therefore, OS1 and OS2 are never 
5 executed simultaneously. A trace name Ax(x: 1 to 4) is given 

to each 0S1 trace and a trace name Bx(x: 1 to 4 ) is given 
to each 0S2 trace. SI indicates a transmission trace in 
inter-OS communications and Rl indicates a received trace 
in the inter-OS communications. 
; p : 10 At first, the trace of Al ( 507-1) was recorded at an 

: : ^ ! OSl managed time 10:00:00, then A2 ( 507-2 ) and A3 (507-3) were 

tt h recorded at 10:00:01 and 10:00:03 respectively. Then, at 

an OSl managed time 10:00:05, data was transmitted (509- 

[l-j 1) from OSl to OS2, thereby the transmitted trace SI (507-4) 

i %J 

Q 15 was recorded as an OSl trace. At this time, a received trace 

Rl ( 508-1) was recorded as an OS2 trace at the data receiving 
side. After that, OS switching (509-2, 509-3) was repeated, 
thereby traces of A4 ( 507-5 ) and Bl to B4 ( 508-2 to 508-5 ) were 
recorded in both OSl and OS2. During this time, Al to A4 

20 and SI (507-1 to 507-5) were recorded as OSl traces together 

with OSl managed times in the OSl operation trace 
information in order they were generated. On the other hand, 
Bl to B4 and Rl ( 508-1 to 508-5) were recorded as OS2 traces 
together with OS2 managed times in the OS2 operation trace 

25 information in order they were generated. 



The trace log editing/displaying program 401 edits 
and displays actually generated traces in order they are 
generated according to the OS1 operation trace information 
311 and the OS2 operation trace information 312. 
Consequently , the program 401 searches a pair of inter-OS 
communication traces to be assumed as check points from the 
operation trace information items of both OS1 and 0S2 . In 
this case, if a trace SI (507-4) corresponding to a 
transmission event is found from the OS1 operation trace 
information and a trace Rl ( 508-1) corresponding to an 
received event from the OS2 operation trace information, 
then the SI (507-4) stored in the 0S1 operation trace 
information is decided as a reference point. The SI was 
generated at an OS1 managed time 10:00:05. This time is used 
as a reference point so as to calculate the relative times 
of Al to A4 as follows . 

Relative time = trace generated time- reference point 
generated time 

It is thus found that Al takes -5sec, A2 takes -4sec, 
A3 takes -2sec, and A4 takes 7sec. In the same way, relative 
times of Bl to B4 in OS2 are calculated and found as follows. 
The reference point is decided by regarding that a trace 
Rl( 508-1) is generated together with SI (507-4) at the same 
time. Because the OS2 managed time is 10:00:35 at that time, 
Bl takes lsec, B2 takes 2sec, B3 takes 9sec, and B4 takes 



lOsec. The above results are displayed so that the time axis 
is taken in the vertical direction (from top to bottom) and 
OS1 traces are shown at the left side and OS2 traces are shown 
at the right side. The traces are also displayed in the 
format of one trace per line in ascending order of 
calculation results of the above relative times. Since the 
inter-OS traces are generated simultaneously in both OS1 and 
OS2, they are displayed on the same line. The 
synchronization traces may also be displayed in a thick line 
frame respectively or in different colors. 

Next, a description will be made for the trace log 
editing/displaying system in the second embodiment of the 
present invention with reference to Fig. 8. In this 
embodiment, a difference between OS1 and OS2 managed times 
is used to edit and display trace information of both OS1 
and 0S2. Fig. 8 is an overall block diagram of the trace log 
editing/displaying system in the second embodiment. In this 
second embodiment of the present invention, a control 
program 201 stores information related to a difference 
between OS1 and OS2 managed times as an inter-OS time 
difference 202. 

It is premised here that the control program 201 reads 
the times managed by both OS1 and 0S2 simultaneously and 
writes the time difference between OS1 and OS2 managed times 
in the time lag information 202 . In this embodiment, it will 



be found that the 0S2 managed time is 10:00:30 (202-2) when 
the OS1 managed time is 10:00:00(202-1) and the OS2 managed 
time is 11:00:32 (202-4) when the OS1 managed time is 
11:00:00(202-3), and the OS2 managed time is 12:00:34 
(202-6) when the OS1 managed time is 12:00:01(202-1). 

In this second embodiment, neither the OS1 operation 
trace information 311 nor the OS2 operation trace 
information 312 includes any check point trace. If traces 
are edited and displayed sequentially in order they are 
actually generated according to the time lag information and 
the operation trace information of both OS1 and OS2, the OS2 
time in an OS1 time can be known from the time lag information 
202. With use of this time difference as a reference point, 
relative times of generated traces in the operation trace 
information of both OS1 and OS2 are calculated as follows. 

Relative time = trace generation time - reference 
point generation time 

The relative time of each generated 0S2 trace is also 
calculated in the same way. The calculation results are then 
displayed so that the time axis is taken in the vertical 
direction (from top to bottom) and OS1 traces are shown at 
the left side and 0S2 traces are shown at the right side. 
The sequence of those traces in generation is displayed in 
ascending order of calculation results (from top to bottom) 
in the format of one trace per line. OS1 traces and OS2 
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traces may also be displayed in different colors for easier 
distinction. For example , 0S1 traces may be displayed in 
green and 0S2 traces may be displayed in red. In this second 
embodiment , when comparing an 0S1 trace with an OS2 trace , 
it is required that the object trace recording time band is 
found from the time lag information 202, then the found time 
band is compensated accordingly. As this time lag 
information, the control program 201 can read the times from 
both OS1 and OS2 and stores them as they are, as well as the 
program 201 can store the time difference as a time 
deviation. 

Next, a description will be made for the third 
embodiment of the trace log editing/displaying system of the 
present invention with reference to Fig. 9. In this 
embodiment, counter information is used to edit and display 
the trance information items of both OS1 and OS2. In this 
case, because each trace recorded in each OS is corresponded 
to the counter information 203 managed by the control 
program 201, the order of each trace is decided uniquely in 
each of the OS1 and OS2. 

Fig. 9 shows an overall block diagram of the trace log 
editing/displaying system when counter information is used. 
The control program 201 has counter information 2 03 in 
itself. It is premised here that when the program Pi (313) 
in the OS1 or the program P2(323) in the OS2 records a trace, 
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the present counter value is read from the counter 
information 203 set in the control program 201. The read 
counter value is then stored in the trace information of both 
OS1 and OS2 together with the trace data by the program Pi 
5 or P2 in the OS1 or OS2. The counter information 203 in the 

control program 201 is incremented by one each time it is 
read. In the operation trace information (311 , 312) of both 
OS1 and 0S2 are recorded OS time information , trace data, 
and the counter value respectively. Because the counter 

10 value is incremented by one each time a trace is recorded, 

a trace with a smaller value is generated earlier than a 
trace with a larger value. Consequently, if operation trace 
information items of both OS 1 and OS2 are merged and the 
counter values are sorted in ascending order, then traces 

15 are listed up in order they are actually generated. Unlike 

the above embodiments, it is no need to search the 
correspondence among check point traces in this second 
embodiment. 

Next, a description will be made for the trace log 
20 editing/displaying system of the present invention in 

another embodiment with reference to Fig. 10. In this 
embodiment, it is premised that the trace log 
editing/displaying program 401 is executed in another 
computer. A computer system 1 operates so that a control 
25 program 201 switches the operating system between OS1 (310) 
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and 0S2 (320) installed in a computer 101. Each of the OS1 
and the OS2 has operation trace information (311, 321) . The 
computer system 2 in which the trace log editing/displaying 
program 401 is executed is hardware, which is different from 
the computer system 1 and OS3 (330) is running in the 
computer 121. The computer 121 is connected to a display 
unit 102 for displaying traces. The computer 101 and the 
computer 121 are connected to each other via a network 122 
so as to transfer operation trace information between them. 
Such a data storing medium as a floppy disk, etc. may also 
be used as means for transferring such operation trance 
information. 

The trace log editing/displaying program 401 
installed in the computer system 2 reads operation trace 
information items 311 and 321 of both OS1 and OS 2 via the 
network 122 (803, 804), then edits traces transferred from 
two operation trace information items 311 and 312 in 
accordance with the same method of the first embodiment 
(805) and displays the result on the display unit 102 (806) . 

Although the operation trace information items of 
both OS1 and 0S2 are managed by both OS1 and OS2 in the above 
embodiment, it is also possible to store those operation 
trace information items collectively in a common area. In 
such a case, the control program 201 is provided with a 
sub-routine program for storing traces in the operation 



trace information of both OS1 and 0S2 in the common area, 
so that the sub-routine program is used as an interface 
program executed from both 0S1 and 0S2. A program for 
recording traces in OS1 executes this sub-routine, thereby 
recording 0S1 traces in both OS1 and 0S2 operation trace 
information. In the same way, a program for recording traces 
in 0S2 executes this program, thereby recording OS2 traces 
in both 0S1 and 0S2 operation trace information. 
Consequently, traces are recorded in both OS1 and OS2 
operation trace information items in order they are actually 
generated. 

On the other hand, a program for recording traces in 
0S1 and a program for recording traces in OS2 may also store 
those traces directly in both OS1 and OS2 operation trace 
information items in the common area without using such a 
sub-routine. 

INDUSTRIAL APPLICABILITY 

As described above, the operating system management 
system of the present invention can manage times of events 
generated in a plurality of operating systems in an unified 
manner while each of those operating systems has its own 
managed time that is different from others and manages 
traces of each of those operating systems sequentially in 
order they are generated. Consequently, the management 
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system of the present invention can have an effect that error 
analysis and debugging in development can be done 
efficiently in a computer system in which a plurality of 
operating systems are running. The system will thus be very 
5 suitable for managing a computer system in which a plurality 

of operating systems are running. 



